The present invention deals with database reporting systems. More specifically, the present invention deals with a system which enables user-defined formatting for report sections that can be re-used in different reports.
People in finance and accounting departments of companies have many responsibilities. One of the most important responsibilities is to provide financial and management information to stakeholders in the company. The stakeholders require the information on a frequent basis due to the time sensitive nature of the data. In addition, statutory financial reports are required on a formal schedule which can be managed. However, the time frame between closing and distribution is relatively short.
The financial information that is the subject of these reports is not only time sensitive, but it is difficult and time consuming for the finance and accounting department to produce with generic reporting tools or disconnected spreadsheet tools. These tools fail to handle seamless integration in a financial context, and also deliver the unique formatting and conditional formatting requirements imposed by financial calculations.
In the past, database reporting has been quite cumbersome. Different items of information from a database are needed for different types of reports. Also, different users have different preferred formats for the reports generated.
For instances, typically, when defining a report (such as a financial report) the person generating the report must first define the columns which are to be used in the report. An example of columns may be (for example, for aged accounts receivable) a customer name, and then columns of aged accounts receivable which are aged by a certain period, such as 30 days, 60 days, 90 days, etc. When the report is generated, the database system executes a query against a database and expands the rows with the appropriate data. In the example being discussed, the database system will expand the rows to include customer names and then accounts receivable for each of those customers which are 30 days old, 60 days old, and 90 days old, etc.
Also, in previous systems, in order to generate a report, row sets could be defined to appear in the report, as could column sets. Therefore, while different rows and columns could be defined to appear in the report, the user defining the report could not see where the information would appear in the report until the report was actually generated. This is not only time consuming, but is quite cumbersome for a user who is attempting to define a report that needs to be generated.
Similarly, in prior reporting systems, data types were typically defined as part of a row set. For example, a user would define “cash” as having certain inclusions or exclusions in a row set. Therefore, every time the definition of “cash” changed, the user would need to update every reference to cash in the reports.
It can thus be seen that prior reporting systems were difficult to use, because the user could not be presented with a visualization of the report prior to actually generating the report. Prior reporting systems also required a great deal of work in maintaining and updating the reporting system, as definitions of data types changed.